Clean up transition related prop names.#1912
Conversation
…ome use transition. Use the following patterns: - transition for the function or "none" string, which reads well and is clear. - transitionParams for the params specifically tied to the transition.
|
@shinokada is attempting to deploy a commit to the Bergside Team on Vercel. A member of the Team first needs to authorize it. |
📝 WalkthroughWalkthroughRenames public props for transition consistency: Changes
Sequence Diagram(s)(omitted) Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 inconclusive)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. 📜 Recent review detailsConfiguration used: Path: .coderabbit.yml Review profile: CHILL Plan: Pro 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (9)
src/routes/builder/alert/+page.svelte (1)
97-97: Generated code outputs stale prop nameparamsinstead oftransitionParams.The code generator at line 97 still outputs
params={{...}}for the generated code snippet, but the actual API now usestransitionParams. This will produce incorrect example code for users.Proposed fix
- props.push(` params={{${paramsString}}}`); + props.push(` transitionParams={{${paramsString}}}`);src/lib/badge/Badge.svelte (1)
106-106: Documentation comment not updated to reflect the prop rename.The
@propdocumentation still referencesparamsbut the actual prop is nowtransitionParams.📝 Proposed fix
-@prop params +@prop transitionParamssrc/routes/builder/banner/+page.svelte (1)
69-69: Code generator still outputs the oldparamsprop name.The generated code displayed to users will show
params={{...}}instead of the newtransitionParams={{...}}, causing inconsistency with the actual API.📝 Proposed fix
- props.push(` params={{${paramsString}}}`); + props.push(` transitionParams={{${paramsString}}}`);src/routes/builder/popover/+page.svelte (1)
80-80: Code generator still outputs the oldparamsprop name.Same issue as in the Banner builder - the generated code will show
paramsinstead of the newtransitionParams.📝 Proposed fix
- props.push(` params={{${paramsString}}}`); + props.push(` transitionParams={{${paramsString}}}`);src/lib/banner/Banner.svelte (1)
89-89: Documentation comment not updated to reflect the prop rename.The
@propdocumentation still referencesparamsbut the actual prop is nowtransitionParams.📝 Proposed fix
-@prop params +@prop transitionParamssrc/routes/builder/badge/+page.svelte (1)
113-113: Generated code uses outdated prop nameparamsinstead oftransitionParams.The component usage on line 159 correctly uses
transitionParams, but the code generator still outputsparams={{...}}. This will produce invalid code for users copying from the builder.Proposed fix
- props.push(` params={{${paramsString}}}`); + props.push(` transitionParams={{${paramsString}}}`);src/lib/alert/Alert.svelte (1)
114-114: Documentation lists outdated prop nameparamsinstead oftransitionParams.The component's JSDoc block still references
@prop params, but the actual prop is nowtransitionParams.Proposed fix
-@prop params +@prop transitionParamssrc/routes/builder/toast/+page.svelte (1)
65-65: Generated code uses outdated prop nameparamsinstead oftransitionParams.The Toast component usage on line 93 correctly uses
transitionParams, but the code generator outputsparams={{...}}. Users copying this generated code will get invalid props.Proposed fix
- props.push(` params={{${paramsString}}}`); + props.push(` transitionParams={{${paramsString}}}`);src/lib/sidebar/SidebarDropdownWrapper.svelte (1)
104-104: Documentation lists outdated prop nameparamsinstead oftransitionParams.The component's JSDoc block still references
@prop params, but the actual prop is nowtransitionParams.Proposed fix
-@prop params +@prop transitionParams
🤖 Fix all issues with AI agents
In @src/lib/types.ts:
- Line 216: v2 introduced breaking prop renames (transitionType → transition,
params → transitionParams) and the type change to transition?: TransitionFunc |
"none", but the v2-migration-guide.md is empty; update the migration guide to
document these breaking changes by adding a section that lists affected
components (Accordion, Alert, Avatar, Banner, Popover, and the others referenced
around lines noted in the review), show before/after prop examples for
transitionType → transition and params → transitionParams, explain the new
accepted type (TransitionFunc or the literal "none"), and include guidance for
migrating existing code and automated codemods where applicable.
🧹 Nitpick comments (1)
src/lib/sidebar/Sidebar.svelte (1)
82-88: Consider extracting default transition params to reduce duplication.The default transition params object
{ x: -320, duration: 200, easing: sineIn }is repeated. Extracting it improves readability.♻️ Suggested refactor
+ const defaultTransitionParams = { x: -320, duration: 200, easing: sineIn }; + let finalTransitionParams = $derived( isBrowser && prefersReducedMotion.current - ? { ...(transitionParams ? transitionParams : { x: -320, duration: 200, easing: sineIn }), duration: 0 } - : transitionParams - ? transitionParams - : { x: -320, duration: 200, easing: sineIn } + ? { ...(transitionParams ?? defaultTransitionParams), duration: 0 } + : transitionParams ?? defaultTransitionParams );
📜 Review details
Configuration used: Path: .coderabbit.yml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (18)
src/lib/accordion/Accordion.sveltesrc/lib/accordion/AccordionItem.sveltesrc/lib/alert/Alert.sveltesrc/lib/badge/Badge.sveltesrc/lib/banner/Banner.sveltesrc/lib/drawer/Drawer.sveltesrc/lib/forms/select/MultiSelect.sveltesrc/lib/sidebar/Sidebar.sveltesrc/lib/sidebar/SidebarDropdownWrapper.sveltesrc/lib/toast/Toast.sveltesrc/lib/types.tssrc/routes/builder/alert/+page.sveltesrc/routes/builder/badge/+page.sveltesrc/routes/builder/banner/+page.sveltesrc/routes/builder/popover/+page.sveltesrc/routes/builder/toast/+page.sveltesrc/routes/layouts/ComponentsLayout.sveltesrc/tests/accordion/no-transition-accordion.test.svelte
🧰 Additional context used
📓 Path-based instructions (1)
**/*.{svelte,ts,tsx,js,jsx}
📄 CodeRabbit inference engine (AGENTS.md)
**/*.{svelte,ts,tsx,js,jsx}: Use the Flowbite-Svelte MCP server to discover components by name or category before implementing UI components
Always use findComponent tool FIRST to locate the correct Flowbite-Svelte component before fetching documentation
After calling findComponent, use getComponentDoc tool to fetch complete documentation including usage examples, props, and best practices for Flowbite-Svelte components
Files:
src/tests/accordion/no-transition-accordion.test.sveltesrc/routes/builder/badge/+page.sveltesrc/lib/drawer/Drawer.sveltesrc/lib/sidebar/SidebarDropdownWrapper.sveltesrc/lib/types.tssrc/lib/accordion/AccordionItem.sveltesrc/lib/forms/select/MultiSelect.sveltesrc/routes/builder/toast/+page.sveltesrc/routes/builder/popover/+page.sveltesrc/lib/alert/Alert.sveltesrc/lib/sidebar/Sidebar.sveltesrc/lib/badge/Badge.sveltesrc/routes/builder/alert/+page.sveltesrc/routes/builder/banner/+page.sveltesrc/routes/layouts/ComponentsLayout.sveltesrc/lib/toast/Toast.sveltesrc/lib/accordion/Accordion.sveltesrc/lib/banner/Banner.svelte
🧠 Learnings (4)
📚 Learning: 2025-12-16T13:21:19.575Z
Learnt from: shinokada
Repo: themesberg/flowbite-svelte PR: 1882
File: src/lib/bottom-navigation/BottomNavHeaderItem.svelte:9-9
Timestamp: 2025-12-16T13:21:19.575Z
Learning: When using ThemeProvider with reactive themes in Flowbite-Svelte, ensure that getTheme("componentName") calls are placed inside a $derived() expression (not at module scope) so components react to dynamic theme changes. This applies broadly to Svelte components in this repo that rely on theme-derived values. For example:
// bad: at module scope
const theme = getTheme("button");
// good: inside a derived store
import { derived } from 'svelte/store';
const themeDerived = derived(themeProviderStore, ($themeProvider) => getTheme("button"));
// use $themeDerived in template/component
Applied to files:
src/tests/accordion/no-transition-accordion.test.sveltesrc/routes/builder/badge/+page.sveltesrc/lib/drawer/Drawer.sveltesrc/lib/sidebar/SidebarDropdownWrapper.sveltesrc/lib/accordion/AccordionItem.sveltesrc/lib/forms/select/MultiSelect.sveltesrc/routes/builder/toast/+page.sveltesrc/routes/builder/popover/+page.sveltesrc/lib/alert/Alert.sveltesrc/lib/sidebar/Sidebar.sveltesrc/lib/badge/Badge.sveltesrc/routes/builder/alert/+page.sveltesrc/routes/builder/banner/+page.sveltesrc/routes/layouts/ComponentsLayout.sveltesrc/lib/toast/Toast.sveltesrc/lib/accordion/Accordion.sveltesrc/lib/banner/Banner.svelte
📚 Learning: 2024-11-22T08:37:27.996Z
Learnt from: mrh1997
Repo: themesberg/flowbite-svelte PR: 1442
File: src/lib/utils/Popper.svelte:144-145
Timestamp: 2024-11-22T08:37:27.996Z
Learning: In `src/lib/utils/Popper.svelte`, inconsistencies in event handling (e.g., using both `mouseenter`/`mouseleave` and `pointerenter`/`pointerleave`) may be intentional to minimize modifications and reduce the risk of new problems.
Applied to files:
src/lib/drawer/Drawer.sveltesrc/lib/sidebar/SidebarDropdownWrapper.sveltesrc/routes/builder/popover/+page.sveltesrc/lib/sidebar/Sidebar.svelte
📚 Learning: 2024-10-18T09:38:03.879Z
Learnt from: Chizaruu
Repo: themesberg/flowbite-svelte PR: 1465
File: src/lib/forms/Timepicker.svelte:105-116
Timestamp: 2024-10-18T09:38:03.879Z
Learning: In `Timepicker.svelte`, the `Dropdown` opens as intended and is used exclusively with the 'dropdown' and 'timerange-dropdown' Timepicker types.
Applied to files:
src/lib/sidebar/SidebarDropdownWrapper.svelte
📚 Learning: 2025-12-28T05:16:44.735Z
Learnt from: shinokada
Repo: themesberg/flowbite-svelte PR: 0
File: :0-0
Timestamp: 2025-12-28T05:16:44.735Z
Learning: In flowbite-svelte with Svelte 5, props are not reactive by default. To make prop values reactive (so they update when the prop changes), they must be wrapped with `$derived()`. For example, `const styling = $derived(classes)` is necessary—not redundant—to ensure `styling` reacts to changes in the `classes` prop.
Applied to files:
src/lib/accordion/AccordionItem.svelte
🔇 Additional comments (26)
src/lib/drawer/Drawer.svelte (2)
77-82: LGTM!The viewport dimension calculations correctly use the reactive window primitives with proper SSR fallback (
?? 0). The logic for computingxandypositions based on placement remains sound.
2-2: Import path is valid and correct for Svelte 5.The
svelte/reactivity/windowmodule is a standard Svelte 5 export that provides reactive window primitives. The usage ofinnerWidth.currentandinnerHeight.currentwith nullish coalescing (?? 0) for SSR is the idiomatic approach per Svelte 5 documentation.src/tests/accordion/no-transition-accordion.test.svelte (1)
5-5: LGTM!The test correctly uses the renamed
transition="none"prop, aligning with the standardized API.src/lib/forms/select/MultiSelect.svelte (1)
239-248: LGTM!The Badge usage correctly adopts the renamed
transitionParamsprop, consistent with the standardized API across the codebase.src/routes/builder/alert/+page.svelte (1)
137-137: LGTM on the component usage!The Alert component correctly uses
transitionParamsfor the transition parameters.src/routes/layouts/ComponentsLayout.svelte (1)
93-93: LGTM!The Sidebar usage correctly adopts the renamed
transitionParamsprop, consistent with the standardized API.src/lib/badge/Badge.svelte (1)
25-25: Prop rename looks correct.The
transitionParamsprop is correctly destructured and used ineffectiveParamsderivation.Also applies to: 52-52
src/lib/toast/Toast.svelte (1)
19-19: LGTM!The prop rename to
transitionParamsis correctly applied throughout the component, and the documentation comment is properly updated.Also applies to: 37-37, 91-91
src/routes/builder/banner/+page.svelte (1)
107-107: Component usage correctly updated.The Banner component now receives
transitionParamsinstead ofparams.src/routes/builder/popover/+page.svelte (1)
112-112: Component usage correctly updated.The Popover component now receives
transitionParamsinstead ofparams.src/lib/banner/Banner.svelte (1)
21-21: Prop rename correctly applied.The
transitionParamsprop is properly destructured and used ineffectiveParams.Also applies to: 38-38
src/routes/builder/badge/+page.svelte (1)
158-160: LGTM!The prop rename from
paramstotransitionParamsis correctly applied in the component usage.src/lib/alert/Alert.svelte (1)
22-22: LGTM!The prop rename from
paramstotransitionParamsis correctly applied in destructuring and theeffectiveParamsderivation.Also applies to: 49-49
src/routes/builder/toast/+page.svelte (1)
93-93: LGTM!The prop rename from
paramstotransitionParamsis correctly applied in the Toast component usage.src/lib/sidebar/SidebarDropdownWrapper.svelte (1)
11-24: LGTM!The prop rename from
paramstotransitionParamsis correctly applied in destructuring and theeffectiveParamsderivation.Also applies to: 34-34
src/lib/accordion/Accordion.svelte (1)
10-10: LGTM!The prop rename from
transitionTypetotransitionis correctly applied across destructuring, the reactive context getter, and documentation.Also applies to: 19-21, 54-54
src/lib/sidebar/Sidebar.svelte (2)
2-2: LGTM on the reactive window import.Using
innerWidthfromsvelte/reactivity/windowis the idiomatic Svelte 5 approach for reactive window dimensions, replacing the previoussvelte:windowbinding pattern.
25-25: Prop rename and usage updates look correct.The
params→transitionParamsrename is consistently applied throughout: prop declaration, derived values, transition binding, and documentation.Also applies to: 46-46, 156-156, 192-192
src/lib/accordion/AccordionItem.svelte (2)
25-27: Transition detection logic is correct but could be clearer.The logic correctly determines whether to use transitions based on both local prop and context. The chained ternary reads as: "if local
transitionis"none", disable; else if contexttransitionis"none", disable; else enable."
11-11: Prop rename and template updates look correct.The
transitionType→transitionrename is consistently applied in props, template bindings, and documentation. Thetransition:transitionsyntax correctly binds the transition function dynamically.Also applies to: 84-85, 110-110
src/lib/types.ts (6)
216-216: Accordion type definitions correctly updated.
AccordionPropsandAccordionItemPropsnow usetransitioninstead oftransitionType, aligning with the standardized naming convention.Also applies to: 233-233
244-244: Alert, Badge, and Banner type definitions correctly updated.The
params→transitionParamsrename is consistently applied across these interfaces.Also applies to: 273-273, 283-283
354-357: AccordionContextType correctly updated.The context type mirrors the prop changes, ensuring type safety when consuming context values.
1198-1203: PopoverProps correctly updated.The
transitionParamsrename maintains consistency with other popover-like components.
1331-1344: Sidebar-related type definitions correctly updated.Both
SidebarPropsandSidebarDropdownWrapperPropsnow usetransitionParams, ensuring API consistency across sidebar components.Also applies to: 1370-1381
1804-1816: ToastProps correctly updated.The
transitionParamsrename completes the standardization across all toast-related transition configuration.
| children: Snippet; | ||
| multiple?: boolean; | ||
| transitionType?: TransitionFunc | "none"; | ||
| transition?: TransitionFunc | "none"; |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Check if there's a CHANGELOG or migration documentation mentioning these changes
fd -t f -e md . --exec grep -l -i "breaking\|breaking change\|migration" {} \; 2>/dev/null | head -10
# Check current branch
git branch --show-current
# Look for any migration or upgrade documentation
fd -t f "MIGRATION\|UPGRADE\|CHANGELOG" -i
# Check package.json for version info
cat package.json | grep -A2 '"version"'Repository: themesberg/flowbite-svelte
Length of output: 487
🏁 Script executed:
#!/bin/bash
# Check the v2-migration-guide for relevant changes
grep -i "transition\|breaking" v2-migration-guide.md | head -20
# Also check CHANGELOG for these specific prop changes
grep -i "transition\|transitionType\|transitionParams" CHANGELOG.md | head -20
# Examine the types.ts file to see the actual scope of changes
head -230 src/lib/types.ts | tail -20
tail -n +220 src/lib/types.ts | head -40Repository: themesberg/flowbite-svelte
Length of output: 5030
🏁 Script executed:
# Check the v2-migration-guide.md for details about these prop changes
cat v2-migration-guide.md | head -100
# Also check if there are specific migration sections for Drawer/Modal
grep -A5 -B5 "transitionType\|transitionParams" v2-migration-guide.mdRepository: themesberg/flowbite-svelte
Length of output: 97
🏁 Script executed:
# Get the full content of the v2-migration-guide
cat v2-migration-guide.md
# Also check the CHANGELOG for more details about these breaking changes
head -100 CHANGELOG.mdRepository: themesberg/flowbite-svelte
Length of output: 3006
🏁 Script executed:
# Get full v2-migration-guide content
wc -l v2-migration-guide.md
cat v2-migration-guide.md
# Also search for specific mention of transition changes
grep -n "transition\|Transition" v2-migration-guide.mdRepository: themesberg/flowbite-svelte
Length of output: 121
🏁 Script executed:
# Check the actual content and size of v2-migration-guide.md
cat v2-migration-guide.md | wc -c
file v2-migration-guide.md
# Get more context from the types.ts file around the specified lines
sed -n '200,250p' src/lib/types.ts
# Also check lines around 273, 283, 356, etc.
sed -n '270,290p' src/lib/types.ts
sed -n '350,360p' src/lib/types.ts
sed -n '1195,1210p' src/lib/types.tsRepository: themesberg/flowbite-svelte
Length of output: 3101
🏁 Script executed:
# Let's find where the old prop names (transitionType, params) were used
# to understand if this is truly a breaking change
rg "transitionType|params" src/lib/ -t ts -t tsx | head -20
# Check git log for recent changes to types.ts
git log --oneline -20 src/lib/types.ts
# Look for any documentation in PR descriptions or commits mentioning these changes
git log --all --grep="transitionType\|transitionParams" --oneline
# Check if there are any test files that might show the old vs new prop usage
fd -t f "\.test\|\.spec" src/ | head -5Repository: themesberg/flowbite-svelte
Length of output: 710
🏁 Script executed:
# Get more details about the migration guide - check if it's truly empty
wc -l v2-migration-guide.md
head -200 v2-migration-guide.md
tail -50 v2-migration-guide.md
# Check the specific commit that made these changes
git show 5b8fdd97 --stat | head -30
# Look at the commit message in detail
git log -1 --format="%B" 5b8fdd97Repository: themesberg/flowbite-svelte
Length of output: 2216
Breaking change documented in major version but missing from migration guide.
These prop renames (transitionType → transition, params → transitionParams) are intentional breaking changes as part of v2.0.0-next.8 (standardizing inconsistent prop naming). However, the v2-migration-guide.md appears incomplete—it contains only a header with no actual migration content. While the CHANGELOG mentions breaking changes in general terms (v2.0.0-next.5), these specific prop renames should be documented with before/after examples in the migration guide.
Consider expanding v2-migration-guide.md to include sections documenting the transition property changes across affected components (Accordion, Alert, Avatar, Banner, Popover, and others listed at lines 233-234, 244, 273, 283, 356, 1202, 1339, 1378, 1813).
🤖 Prompt for AI Agents
In @src/lib/types.ts at line 216, v2 introduced breaking prop renames
(transitionType → transition, params → transitionParams) and the type change to
transition?: TransitionFunc | "none", but the v2-migration-guide.md is empty;
update the migration guide to document these breaking changes by adding a
section that lists affected components (Accordion, Alert, Avatar, Banner,
Popover, and the others referenced around lines noted in the review), show
before/after prop examples for transitionType → transition and params →
transitionParams, explain the new accepted type (TransitionFunc or the literal
"none"), and include guidance for migrating existing code and automated codemods
where applicable.
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (2)
src/routes/builder/drawer/+page.svelte (1)
79-79: Generated code still emitstransitionTypeinstead oftransition.The PR objective is to rename
transitionTypetotransition. While line 91 correctly usestransitionParams, line 79 still emits the oldtransitionTypeprop name in the generated code. This should be updated for consistency.🔧 Suggested fix
if (currentTransition !== transitions[0]) { - props.push(` transitionType={${currentTransition.transition.name}}`); + props.push(` transition={${currentTransition.transition.name}}`);src/routes/docs-examples/components/accordion/TransitionNone.svelte (1)
17-22: Update header text to reflect the renamed prop.The prop on line 17 correctly uses
transition="none", but the header snippets on lines 18 and 22 still reference the oldtransitionTypename. Update these to maintain consistency with the new API.Proposed fix
<AccordionItem transition="none"> - {#snippet header()}transitionType: "none"{/snippet} + {#snippet header()}transition: "none"{/snippet} Content C </AccordionItem> <AccordionItem> - {#snippet header()}transitionType: default{/snippet} + {#snippet header()}transition: default{/snippet} Content D </AccordionItem>
🤖 Fix all issues with AI agents
In @v2-migration-guide.md:
- Around line 8-13: The component list under "Lists affected components" is
incomplete for the params → transitionParams rename; update that section to
include Badge, Toast, Sidebar, and SidebarDropdownWrapper so the migration guide
lists Accordion, Alert, Avatar, Banner, Popover, Badge, Toast, Sidebar, and
SidebarDropdownWrapper to reflect all affected components referenced in the PR.
📜 Review details
Configuration used: Path: .coderabbit.yml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (42)
src/lib/alert/Alert.sveltesrc/lib/badge/Badge.sveltesrc/lib/banner/Banner.sveltesrc/lib/sidebar/Sidebar.sveltesrc/lib/sidebar/SidebarDropdownWrapper.sveltesrc/routes/admin-dashboard/(sidebar)/Sidebar.sveltesrc/routes/builder/alert/+page.sveltesrc/routes/builder/badge/+page.sveltesrc/routes/builder/banner/+page.sveltesrc/routes/builder/drawer/+page.sveltesrc/routes/builder/dropdown/+page.sveltesrc/routes/builder/modal/+page.sveltesrc/routes/builder/popover/+page.sveltesrc/routes/builder/toast/+page.sveltesrc/routes/docs-examples/components/accordion/TransitionNone.sveltesrc/routes/docs-examples/components/accordion/Transitions.sveltesrc/routes/docs-examples/components/alert/Dismissable.sveltesrc/routes/docs-examples/components/banner/Transition.sveltesrc/routes/docs-examples/components/sidebar/AllOpen.sveltesrc/routes/docs-examples/components/sidebar/AlwaysOpen.sveltesrc/routes/docs-examples/components/sidebar/Branding.sveltesrc/routes/docs-examples/components/sidebar/BrandingUsingChildren.sveltesrc/routes/docs-examples/components/sidebar/CloseButton.sveltesrc/routes/docs-examples/components/sidebar/Cta.sveltesrc/routes/docs-examples/components/sidebar/Default.sveltesrc/routes/docs-examples/components/sidebar/LinksAndActive.sveltesrc/routes/docs-examples/components/sidebar/LinksAndActive2.sveltesrc/routes/docs-examples/components/sidebar/MultiLevel.sveltesrc/routes/docs-examples/components/sidebar/MultiLevel2.sveltesrc/routes/docs-examples/components/sidebar/ObjectEx.sveltesrc/routes/docs-examples/components/sidebar/Separator.sveltesrc/routes/docs-examples/components/sidebar/Single.sveltesrc/routes/docs-examples/components/sidebar/Static.sveltesrc/routes/docs-examples/components/sidebar/Transition.sveltesrc/routes/docs-examples/components/toast/Blur.sveltesrc/routes/docs-examples/components/toast/Fly.sveltesrc/routes/docs-examples/components/toast/StackVertical.sveltesrc/routes/docs-examples/components/toast/ToastContainerEx.sveltesrc/routes/docs-examples/components/toast/Transitions.sveltesrc/routes/docs-examples/forms/select/Customization.sveltesrc/routes/docs-examples/forms/select/Preselect.sveltev2-migration-guide.md
🚧 Files skipped from review as they are similar to previous changes (6)
- src/routes/builder/alert/+page.svelte
- src/routes/builder/badge/+page.svelte
- src/lib/sidebar/Sidebar.svelte
- src/lib/banner/Banner.svelte
- src/lib/badge/Badge.svelte
- src/routes/builder/banner/+page.svelte
🧰 Additional context used
📓 Path-based instructions (1)
**/*.{svelte,ts,tsx,js,jsx}
📄 CodeRabbit inference engine (AGENTS.md)
**/*.{svelte,ts,tsx,js,jsx}: Use the Flowbite-Svelte MCP server to discover components by name or category before implementing UI components
Always use findComponent tool FIRST to locate the correct Flowbite-Svelte component before fetching documentation
After calling findComponent, use getComponentDoc tool to fetch complete documentation including usage examples, props, and best practices for Flowbite-Svelte components
Files:
src/routes/docs-examples/components/sidebar/Branding.sveltesrc/routes/docs-examples/components/toast/StackVertical.sveltesrc/routes/docs-examples/components/sidebar/AlwaysOpen.sveltesrc/routes/builder/dropdown/+page.sveltesrc/routes/admin-dashboard/(sidebar)/Sidebar.sveltesrc/routes/docs-examples/components/sidebar/LinksAndActive2.sveltesrc/routes/docs-examples/components/sidebar/MultiLevel.sveltesrc/routes/builder/modal/+page.sveltesrc/routes/docs-examples/components/sidebar/Separator.sveltesrc/routes/docs-examples/components/accordion/Transitions.sveltesrc/routes/docs-examples/components/toast/ToastContainerEx.sveltesrc/routes/docs-examples/components/sidebar/Default.sveltesrc/routes/builder/popover/+page.sveltesrc/lib/alert/Alert.sveltesrc/routes/docs-examples/forms/select/Preselect.sveltesrc/lib/sidebar/SidebarDropdownWrapper.sveltesrc/routes/docs-examples/components/sidebar/LinksAndActive.sveltesrc/routes/docs-examples/components/sidebar/Cta.sveltesrc/routes/docs-examples/components/toast/Fly.sveltesrc/routes/docs-examples/components/sidebar/MultiLevel2.sveltesrc/routes/docs-examples/components/sidebar/BrandingUsingChildren.sveltesrc/routes/docs-examples/forms/select/Customization.sveltesrc/routes/docs-examples/components/sidebar/AllOpen.sveltesrc/routes/docs-examples/components/sidebar/Single.sveltesrc/routes/docs-examples/components/sidebar/ObjectEx.sveltesrc/routes/docs-examples/components/toast/Transitions.sveltesrc/routes/docs-examples/components/banner/Transition.sveltesrc/routes/docs-examples/components/alert/Dismissable.sveltesrc/routes/docs-examples/components/sidebar/CloseButton.sveltesrc/routes/docs-examples/components/sidebar/Transition.sveltesrc/routes/builder/drawer/+page.sveltesrc/routes/docs-examples/components/sidebar/Static.sveltesrc/routes/builder/toast/+page.sveltesrc/routes/docs-examples/components/accordion/TransitionNone.sveltesrc/routes/docs-examples/components/toast/Blur.svelte
🧠 Learnings (3)
📓 Common learnings
Learnt from: jjagielka
Repo: themesberg/flowbite-svelte PR: 1819
File: src/lib/tour/Tour.svelte:21-24
Timestamp: 2025-11-03T10:08:17.733Z
Learning: In Svelte 5 components, custom event handler props should follow the lowercase naming convention (e.g., `oncomplete`, `onskip`, `onopen`) rather than camelCase (e.g., `onComplete`, `onSkip`, `onOpen`), consistent with DOM event handlers like `onclick`, `onchange`, etc.
Learnt from: shinokada
Repo: themesberg/flowbite-svelte PR: 0
File: :0-0
Timestamp: 2025-12-28T05:16:44.735Z
Learning: In flowbite-svelte with Svelte 5, props are not reactive by default. To make prop values reactive (so they update when the prop changes), they must be wrapped with `$derived()`. For example, `const styling = $derived(classes)` is necessary—not redundant—to ensure `styling` reacts to changes in the `classes` prop.
Learnt from: mrh1997
Repo: themesberg/flowbite-svelte PR: 1442
File: src/lib/utils/Popper.svelte:144-145
Timestamp: 2024-11-22T08:37:27.996Z
Learning: In `src/lib/utils/Popper.svelte`, inconsistencies in event handling (e.g., using both `mouseenter`/`mouseleave` and `pointerenter`/`pointerleave`) may be intentional to minimize modifications and reduce the risk of new problems.
Learnt from: jjagielka
Repo: themesberg/flowbite-svelte PR: 1745
File: src/lib/forms/checkbox/CheckboxButton.svelte:16-17
Timestamp: 2025-08-31T14:31:57.582Z
Learning: In Svelte 5, the `on:event` syntax for event forwarding is obsolete. Event handlers are passed as callback props (e.g., `onchange`, `oninput`) through `{...restProps}` instead of using `on:change`, `on:input` etc.
📚 Learning: 2025-12-16T13:21:19.575Z
Learnt from: shinokada
Repo: themesberg/flowbite-svelte PR: 1882
File: src/lib/bottom-navigation/BottomNavHeaderItem.svelte:9-9
Timestamp: 2025-12-16T13:21:19.575Z
Learning: When using ThemeProvider with reactive themes in Flowbite-Svelte, ensure that getTheme("componentName") calls are placed inside a $derived() expression (not at module scope) so components react to dynamic theme changes. This applies broadly to Svelte components in this repo that rely on theme-derived values. For example:
// bad: at module scope
const theme = getTheme("button");
// good: inside a derived store
import { derived } from 'svelte/store';
const themeDerived = derived(themeProviderStore, ($themeProvider) => getTheme("button"));
// use $themeDerived in template/component
Applied to files:
src/routes/docs-examples/components/sidebar/Branding.sveltesrc/routes/docs-examples/components/toast/StackVertical.sveltesrc/routes/docs-examples/components/sidebar/AlwaysOpen.sveltesrc/routes/builder/dropdown/+page.sveltesrc/routes/admin-dashboard/(sidebar)/Sidebar.sveltesrc/routes/docs-examples/components/sidebar/LinksAndActive2.sveltesrc/routes/docs-examples/components/sidebar/MultiLevel.sveltesrc/routes/builder/modal/+page.sveltesrc/routes/docs-examples/components/sidebar/Separator.sveltesrc/routes/docs-examples/components/accordion/Transitions.sveltesrc/routes/docs-examples/components/toast/ToastContainerEx.sveltesrc/routes/docs-examples/components/sidebar/Default.sveltesrc/routes/builder/popover/+page.sveltesrc/lib/alert/Alert.sveltesrc/routes/docs-examples/forms/select/Preselect.sveltesrc/lib/sidebar/SidebarDropdownWrapper.sveltesrc/routes/docs-examples/components/sidebar/LinksAndActive.sveltesrc/routes/docs-examples/components/sidebar/Cta.sveltesrc/routes/docs-examples/components/toast/Fly.sveltesrc/routes/docs-examples/components/sidebar/MultiLevel2.sveltesrc/routes/docs-examples/components/sidebar/BrandingUsingChildren.sveltesrc/routes/docs-examples/forms/select/Customization.sveltesrc/routes/docs-examples/components/sidebar/AllOpen.sveltesrc/routes/docs-examples/components/sidebar/Single.sveltesrc/routes/docs-examples/components/sidebar/ObjectEx.sveltesrc/routes/docs-examples/components/toast/Transitions.sveltesrc/routes/docs-examples/components/banner/Transition.sveltesrc/routes/docs-examples/components/alert/Dismissable.sveltesrc/routes/docs-examples/components/sidebar/CloseButton.sveltesrc/routes/docs-examples/components/sidebar/Transition.sveltesrc/routes/builder/drawer/+page.sveltesrc/routes/docs-examples/components/sidebar/Static.sveltesrc/routes/builder/toast/+page.sveltesrc/routes/docs-examples/components/accordion/TransitionNone.sveltesrc/routes/docs-examples/components/toast/Blur.svelte
📚 Learning: 2024-11-22T08:37:27.996Z
Learnt from: mrh1997
Repo: themesberg/flowbite-svelte PR: 1442
File: src/lib/utils/Popper.svelte:144-145
Timestamp: 2024-11-22T08:37:27.996Z
Learning: In `src/lib/utils/Popper.svelte`, inconsistencies in event handling (e.g., using both `mouseenter`/`mouseleave` and `pointerenter`/`pointerleave`) may be intentional to minimize modifications and reduce the risk of new problems.
Applied to files:
src/routes/docs-examples/components/sidebar/AlwaysOpen.sveltesrc/routes/docs-examples/components/sidebar/MultiLevel.sveltesrc/routes/builder/popover/+page.sveltesrc/lib/sidebar/SidebarDropdownWrapper.sveltesrc/routes/docs-examples/components/sidebar/Cta.sveltesrc/routes/docs-examples/components/sidebar/AllOpen.svelte
🔇 Additional comments (45)
src/routes/builder/dropdown/+page.svelte (1)
94-94: LGTM!The code generator now correctly emits
transitionParamsinstead ofparams, aligning with the standardized prop naming convention across the codebase.src/routes/builder/drawer/+page.svelte (1)
91-91: LGTM!The code generator now correctly emits
transitionParamsfor transition parameters.src/routes/builder/modal/+page.svelte (1)
65-65: LGTM!The code generator correctly emits
transitionParamsfor transition parameters, consistent with the standardized prop naming.src/lib/alert/Alert.svelte (3)
22-22: LGTM!The prop rename from
paramstotransitionParamsis correctly implemented and follows the standardized naming convention.
49-49: LGTM!The derived
effectiveParamscorrectly references the renamedtransitionParamsprop while preserving the reduced motion accessibility behavior.
114-114: LGTM!Documentation comment correctly updated to reflect the
transitionParamsprop name.src/routes/docs-examples/components/toast/StackVertical.svelte (1)
62-62: LGTM!The Toast component usage correctly updated to use
transitionParamsinstead ofparams, keeping the documentation example aligned with the new API.src/routes/docs-examples/components/sidebar/Separator.svelte (1)
24-24: Prop rename looks correct.The change from
paramstotransitionParamsaligns with the PR objective to standardize transition-related prop names across the codebase.src/routes/docs-examples/components/toast/ToastContainerEx.svelte (1)
78-78: Prop rename is consistent with the standardization effort.The update from
paramstotransitionParamscorrectly follows the new naming convention. Thetransition={fly}andtransitionParams={{ x: 200, duration: 800 }}pairing demonstrates the intended API pattern clearly.src/routes/docs-examples/components/sidebar/Cta.svelte (1)
24-24: LGTM!The prop rename to
transitionParamsis consistent with other Sidebar examples in this PR.src/routes/docs-examples/components/sidebar/CloseButton.svelte (1)
24-24: LGTM!The prop rename to
transitionParamsis consistent with the standardization effort across Sidebar examples.src/routes/docs-examples/components/sidebar/Branding.svelte (1)
29-29: LGTM!The prop rename to
transitionParamsmaintains consistency with the other Sidebar documentation examples.src/routes/docs-examples/components/sidebar/LinksAndActive2.svelte (1)
26-26: LGTM!The prop rename from
paramstotransitionParamscorrectly aligns with the standardized transition-related prop naming convention introduced in this PR.src/routes/docs-examples/components/sidebar/Static.svelte (1)
26-26: LGTM!The prop rename to
transitionParamsis consistent with the standardized naming convention.src/routes/docs-examples/components/toast/Blur.svelte (2)
7-12: LGTM!The prop rename to
transitionParamscorrectly standardizes the API while preserving the transition configuration.
14-19: LGTM!Consistent prop rename applied to the second Toast instance.
src/routes/docs-examples/components/toast/Transitions.svelte (2)
15-20: LGTM!The prop rename to
transitionParamsis correctly applied with the scale transition configuration.
22-27: LGTM!The prop rename is correctly applied for the default fade transition case, demonstrating that
transitionParamsworks independently when no explicittransitionprop is provided.src/routes/docs-examples/components/sidebar/Default.svelte (1)
24-24: LGTM!The prop rename from
paramstotransitionParamscorrectly aligns with the standardization effort for transition-related props across the codebase.src/routes/docs-examples/forms/select/Customization.svelte (1)
16-16: LGTM!The prop rename from
paramstotransitionParamson the Badge component is consistent with the codebase-wide standardization of transition-related prop names.src/routes/docs-examples/components/sidebar/AlwaysOpen.svelte (1)
24-24: LGTM!The prop rename is consistent with the standardization effort and matches the pattern used in other Sidebar examples.
src/routes/docs-examples/components/sidebar/MultiLevel.svelte (1)
32-32: LGTM!The prop rename correctly applies the
transitionParamsnaming convention to this multi-level Sidebar example.src/routes/docs-examples/components/accordion/Transitions.svelte (2)
11-11: LGTM!The rename from
transitionTypetotransitioncorrectly follows the new naming convention. The prop now clearly indicates it receives a transition function.
15-15: LGTM!Consistent with the standardized naming pattern for the
transitionprop.src/routes/docs-examples/forms/select/Preselect.svelte (1)
16-16: LGTM!The prop rename from
paramstotransitionParamscorrectly follows the PR's standardization pattern for transition-related props.src/routes/docs-examples/components/sidebar/AllOpen.svelte (1)
25-25: LGTM!The prop rename from
paramstotransitionParamsaligns with the PR's standardization of transition-related props for the Sidebar component.src/routes/docs-examples/components/sidebar/MultiLevel2.svelte (1)
30-30: LGTM!The prop rename to
transitionParamsis correctly applied, consistent with other Sidebar examples in this PR.src/routes/docs-examples/components/sidebar/ObjectEx.svelte (1)
48-48: LGTM!The prop rename to
transitionParamsis correctly applied, maintaining consistency across the Sidebar documentation examples.src/routes/docs-examples/components/sidebar/Single.svelte (1)
24-24: LGTM!The prop rename to
transitionParamsis correctly applied, completing the standardization across Sidebar documentation examples.src/routes/admin-dashboard/(sidebar)/Sidebar.svelte (1)
127-127: LGTM!The prop rename from
paramstotransitionParamsis correctly applied, aligning with the PR's standardization effort.src/routes/docs-examples/components/toast/Fly.svelte (1)
7-18: LGTM!Both Toast components correctly use the new
transitionParamsprop name while maintaining the same transition behavior (fly with x/y offsets).src/routes/docs-examples/components/sidebar/BrandingUsingChildren.svelte (1)
24-24: LGTM!The prop rename from
paramstotransitionParamsis correctly applied, consistent with the Sidebar component's updated API.src/routes/docs-examples/components/alert/Dismissable.svelte (1)
25-28: LGTM!The Alert component correctly uses the new
transitionParamsprop alongside thetransitionprop for the custom fly animation.src/routes/builder/popover/+page.svelte (2)
80-80: LGTM!The code generator correctly outputs
transitionParamsfor the generated Popover code snippet.
112-112: LGTM!The Popover component usage correctly passes
transitionParams={currentTransition.params}, aligning the live preview with the generated code output.src/routes/docs-examples/components/accordion/TransitionNone.svelte (1)
5-5: LGTM!The
transition="none"prop correctly reflects the renamed API fromtransitionType.src/routes/docs-examples/components/banner/Transition.svelte (1)
13-13: LGTM!The Banner now correctly uses the explicit
transitionParamsprop name instead of the shorthand{params}, aligning with the standardized API.src/routes/builder/toast/+page.svelte (2)
65-65: LGTM!The code generator correctly outputs
transitionParamsin the generated code snippet, ensuring users see the correct prop name.
93-93: LGTM!The Toast component correctly uses
transitionParams={currentTransition.params}with the standardized prop name.src/lib/sidebar/SidebarDropdownWrapper.svelte (3)
11-24: LGTM!Props destructuring correctly uses
transitionParamswith the standardized naming convention.
34-34: LGTM!The
effectiveParamsderivation correctly referencestransitionParamswhile preserving the reduced-motion accessibility handling.
104-104: LGTM!JSDoc prop documentation correctly reflects the renamed
transitionParamsprop.src/routes/docs-examples/components/sidebar/LinksAndActive.svelte (1)
26-26: LGTM!The Sidebar correctly uses
transitionParamswith the standardized prop name.src/routes/docs-examples/components/sidebar/Transition.svelte (2)
30-30: LGTM!The
transitionParamsprop is correctly applied to theSidebarcomponent, aligning with the standardized naming convention introduced by this PR.
41-41: LGTM!The
SidebarDropdownWrappercorrectly uses both standardized props:
transition={fade}for the transition functiontransitionParams={params}for the transition parametersThis aligns well with the PR's objective to adopt consistent naming patterns across the codebase.
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Fix all issues with AI agents
In @v2-migration-guide.md:
- Around line 20-23: The sentence "The component classes has the highest
precedence." in the "Order of styling" section uses the singular verb "has" with
the plural noun "classes"; change it to "have" so it reads "The component
classes have the highest precedence." to correct subject-verb agreement.
🧹 Nitpick comments (1)
v2-migration-guide.md (1)
3-18: Documentation clarity improvements.A few minor suggestions to improve the migration guide:
- Line 9: The heading "Lists affected components" reads awkwardly—consider changing to "Affected components".
- Consider whether
AccordionItemshould be listed separately since it also has thetransitionprop (though it inherits fromAccordion's context).📝 Suggested improvements
-### Lists affected components +### Affected components
📜 Review details
Configuration used: Path: .coderabbit.yml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (6)
src/routes/builder/drawer/+page.sveltesrc/routes/component-data/Accordion.jsonsrc/routes/component-data/AccordionItem.jsonsrc/routes/docs-examples/components/accordion/TransitionNone.sveltesrc/routes/docs/components/accordion.mdv2-migration-guide.md
🚧 Files skipped from review as they are similar to previous changes (1)
- src/routes/builder/drawer/+page.svelte
🧰 Additional context used
📓 Path-based instructions (1)
**/*.{svelte,ts,tsx,js,jsx}
📄 CodeRabbit inference engine (AGENTS.md)
**/*.{svelte,ts,tsx,js,jsx}: Use the Flowbite-Svelte MCP server to discover components by name or category before implementing UI components
Always use findComponent tool FIRST to locate the correct Flowbite-Svelte component before fetching documentation
After calling findComponent, use getComponentDoc tool to fetch complete documentation including usage examples, props, and best practices for Flowbite-Svelte components
Files:
src/routes/docs-examples/components/accordion/TransitionNone.svelte
🧠 Learnings (2)
📓 Common learnings
Learnt from: jjagielka
Repo: themesberg/flowbite-svelte PR: 1819
File: src/lib/tour/Tour.svelte:21-24
Timestamp: 2025-11-03T10:08:17.733Z
Learning: In Svelte 5 components, custom event handler props should follow the lowercase naming convention (e.g., `oncomplete`, `onskip`, `onopen`) rather than camelCase (e.g., `onComplete`, `onSkip`, `onOpen`), consistent with DOM event handlers like `onclick`, `onchange`, etc.
Learnt from: shinokada
Repo: themesberg/flowbite-svelte PR: 0
File: :0-0
Timestamp: 2025-12-28T05:16:44.735Z
Learning: In flowbite-svelte with Svelte 5, props are not reactive by default. To make prop values reactive (so they update when the prop changes), they must be wrapped with `$derived()`. For example, `const styling = $derived(classes)` is necessary—not redundant—to ensure `styling` reacts to changes in the `classes` prop.
Learnt from: mrh1997
Repo: themesberg/flowbite-svelte PR: 1442
File: src/lib/utils/Popper.svelte:144-145
Timestamp: 2024-11-22T08:37:27.996Z
Learning: In `src/lib/utils/Popper.svelte`, inconsistencies in event handling (e.g., using both `mouseenter`/`mouseleave` and `pointerenter`/`pointerleave`) may be intentional to minimize modifications and reduce the risk of new problems.
Learnt from: jjagielka
Repo: themesberg/flowbite-svelte PR: 1745
File: src/lib/forms/checkbox/CheckboxButton.svelte:16-17
Timestamp: 2025-08-31T14:31:57.582Z
Learning: In Svelte 5, the `on:event` syntax for event forwarding is obsolete. Event handlers are passed as callback props (e.g., `onchange`, `oninput`) through `{...restProps}` instead of using `on:change`, `on:input` etc.
📚 Learning: 2025-12-16T13:21:19.575Z
Learnt from: shinokada
Repo: themesberg/flowbite-svelte PR: 1882
File: src/lib/bottom-navigation/BottomNavHeaderItem.svelte:9-9
Timestamp: 2025-12-16T13:21:19.575Z
Learning: When using ThemeProvider with reactive themes in Flowbite-Svelte, ensure that getTheme("componentName") calls are placed inside a $derived() expression (not at module scope) so components react to dynamic theme changes. This applies broadly to Svelte components in this repo that rely on theme-derived values. For example:
// bad: at module scope
const theme = getTheme("button");
// good: inside a derived store
import { derived } from 'svelte/store';
const themeDerived = derived(themeProviderStore, ($themeProvider) => getTheme("button"));
// use $themeDerived in template/component
Applied to files:
src/routes/docs-examples/components/accordion/TransitionNone.svelte
🔇 Additional comments (7)
src/routes/component-data/Accordion.json (1)
12-12: LGTM!The prop rename from
transitionTypetotransitionis consistent with the broader standardization effort across the codebase.src/routes/component-data/AccordionItem.json (1)
13-13: LGTM!The prop rename from
transitionTypetotransitionwith default valueslideis consistent with theAccordionItemcomponent implementation and the broader standardization effort.src/routes/docs/components/accordion.md (3)
105-106: LGTM!Documentation correctly updated to reference
transitionandtransitionParamsprops, consistent with the API changes.
133-135: LGTM!Section heading and explanation correctly updated to use
transition="none"syntax.
198-208: LGTM!Component props documentation correctly reflects the renamed props (
transitioninstead oftransitionType) for bothAccordionandAccordionItemcomponents.src/routes/docs-examples/components/accordion/TransitionNone.svelte (2)
5-5: LGTM!Example correctly demonstrates the
transition="none"prop on theAccordioncomponent.
17-22: LGTM!Example correctly demonstrates:
- Per-item
transition="none"override onAccordionItem- Clear header labels showing
transition: "none"vstransition: defaultfor visual comparison
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (2)
v2-migration-guide.md (2)
3-19: Consider adding migration code examples.The breaking changes are documented clearly, but adding before/after code snippets would help users migrate more efficiently.
📝 Example migration snippet to add
+ +### Migration Example + +**Before (v1):** +```svelte +<Accordion transitionType={slide} /> +<Toast params={{ duration: 300 }} /> +``` + +**After (v2):** +```svelte +<Accordion transition={slide} /> +<Toast transitionParams={{ duration: 300 }} /> +```
9-18: Consider sorting the component list alphabetically.Alphabetical ordering would make it easier for users to quickly scan and locate specific components.
📋 Alphabetically sorted list
### Affected Components - Accordion - Alert - Avatar -- Banner - Badge +- Banner - Popover +- Sidebar +- SidebarDropdownWrapper - Toast -- Sidebar -- SidebarDropdownWrapper
📜 Review details
Configuration used: Path: .coderabbit.yml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
v2-migration-guide.md
🧰 Additional context used
🧠 Learnings (1)
📓 Common learnings
Learnt from: jjagielka
Repo: themesberg/flowbite-svelte PR: 1819
File: src/lib/tour/Tour.svelte:21-24
Timestamp: 2025-11-03T10:08:17.733Z
Learning: In Svelte 5 components, custom event handler props should follow the lowercase naming convention (e.g., `oncomplete`, `onskip`, `onopen`) rather than camelCase (e.g., `onComplete`, `onSkip`, `onOpen`), consistent with DOM event handlers like `onclick`, `onchange`, etc.
Learnt from: jjagielka
Repo: themesberg/flowbite-svelte PR: 1745
File: src/lib/forms/checkbox/CheckboxButton.svelte:16-17
Timestamp: 2025-08-31T14:31:57.582Z
Learning: In Svelte 5, the `on:event` syntax for event forwarding is obsolete. Event handlers are passed as callback props (e.g., `onchange`, `oninput`) through `{...restProps}` instead of using `on:change`, `on:input` etc.
1 participant
Clean up transition related prop names. Some use transitionType and some use transition. Use the following patterns:
🔗 Related issue (optional)
Closes #
📑 Description
🔍 PR Type
🚦 PR Status
✅ Checklist
pnpm lint && pnpm check && pnpm test:e2eand all tests passmainbranch (not the published npm version)🧪 Screenshots / Demos (optional)
ℹ️ Additional Information
Summary by CodeRabbit
✏️ Tip: You can customize this high-level summary in your review settings.